Application No. 09/826,266 DocketNo.: 08204/0203163-US0/10.176 

Amendment dated April 21, 2008 

After Final Office Action of February 21, 2008 

REMARKS 

I. Status of Claims 

Prior to entry of this paper, Claims 12-18 were pending. Claims 12-18 were rejected, 
Claims 1-11 and 19-29 were withdrawn from consideration. In this paper, Claims 12 and 13 are 
amended; no claims are cancelled; and no claims are added. Claims 12-18 are currently pending. 
No new matter is added by way of this amendment. For at least the following reasons, Applicant's 
representative respectfully submits that each of the presently pending claims is in condition for 
allowance. 

II. Withdrawal of Finality of previous Office Action 

The reconsideration and withdrawal of the finality of the previous Office Action, mailed 
November 28, 2007, is hereby acknowledged and appreciated. 

III. Request to Reconsider and Withdraw Finality of Current Office Action 

The following factual observations are made with regard to this application: 

1 . The current Office Action, issued February 2 1 , 2008, is Final, as is indicated on both the 
Office Action Summary at 2a, as well as in the "Conclusion" section of the Office Action on page 
21. 

2. In this current Office Action at page 2, section 2, indication is given of the withdrawal of 
the finality of the previous Office Action that was mailed on November 28, 2007. 

3. Also in section 2 on page 2 of the current Office Action, remarks and arguments that 
were made in the Applicant's previous response, filed January 28, 2008, are not answered, whereby 
the Applicant is instead referred to "the response to the arguments of the office action date 1 1/28/07, 
8/14/2007, etc. of the prosecution history". 

4. In the current Office Action, rounds of rejection for Claims 12, 13, and 18, including Gai- 
Cisco in view of Oran-Cisco under 35 U.S.C. § 103(a), are repeated from the previous Office 
Action, including the identical citations in these references that were made in the previous Office 
Action of November 28, 2007. 
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5. The current Office Action, on pages 2-6 and 11-21, also introduces new grounds of 
rejection for at least Claims 12, 13, and 18. These rejections include new references, including 
Sawyer, Lu, Pham, and Short, that had not previously been made of record, nor has then been relied 
upon in rejections in previous Office Actions, including that which was mailed November 28, 2007. 

6. Since at least the previous Office Action of November 28, 2007, no Information 
Disclosure Statements have been filed in this application. 

In the context of such facts, the MPEP at least states the following: 
706.07(d)Final Rejection, Withdrawal of, Premature [R-6] 

Once the finality of the Office action has been withdrawn, the next Office action may be made final if 
the conditions set forth in MPEP § 706.07(a) are met. 

706.07(a)Final Rejection, When Proper on Second Action [R-6] 

Under present practice, second or any subsequent actions on the merits shall be final, except where the examiner 
introduces a new ground of rejection that is neither necessitated by applicant's amendment of the claims, nor based on 
information submitted in an information disclosure statement filed during the period set forth in 37 CFR 1.97(c) with the 
fee set forth in 37 CFR 1.17(p). 

After reviewing the prosecution history of this application, it is respectfully requested that 
the finality of the current Office Action be withdrawn. Particularly, this finality is respectfully 
requested to be withdrawn because the Office Action issued February 21, 2008, includes new 
ground(s) of rejection that were neither necessitated by the applicant's amendment, nor were they 
based on information submitted in an information disclosure statement filed during the period set 
forth in 37 CFR 1.97(c) with the fee set forth in 37 CFR 1.1 7(p). As noted above, rejections based 
on references such as Sawyer, clearly comprise the introduction of new grounds of rejection. 

With regards to the first exception under MPEP 706.07(a), the fact that these new grounds, 
such as those pertaining to Sawyer, are not necessitated by the applicant's amendment of January 
28, 2008, is substantiated by multiple aspects of the current Office Action. First, the repetition of 
the exact same grounds of rejection for the pending claims, Claims 12-18, demonstrates that, even 
without these new grounds of rejection, no pending claim would have otherwise been left without a 
cited ground of rejection. As such, the new grounds of rejection do not provide rejection for claims 
that - amended or otherwise - would not have been rejected under the previously presented grounds 
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of rejection. Second, the current Office Action reference does not provide new responses to the new 
arguments that were presented in the Applicant's previous response regarding the claim 
amendments, which indicates that the Applicant's previous amendments did even not necessitate 
new or additional explanation of the references, much less the new grounds of rejection. It is 
respectfully submitted that these two criteria - the repetition of previous rejections and the reliance 
on prior responses to arguments - cannot logically be valid if the new grounds of rejection were, in 
fact, necessitated by the applicant's previous amendment. As such, it is respectfully submitted that 
the first exception criterion of MPEP 706.07(a) was not met with regards to the finality of the 
current Office Action. 

With regards to the second exception criterion of MPEP 706.07(a), the lack of information 
disclosure statements clearly evidences that the new grounds of rejection, such as Sawyer, are not 
based on a submission of the new grounds of rejection in an Information Disclosure Statement. As 
such, it is respectfully submitted that the second exception criterion of MPEP 706.07(a) was not met 
with regards to the finality of the current Office Action. 

To reiterate, as noted in MPEP 706.07(d), the current Office Action of February 21, 2008 
may be made final if the conditions set forth in MPEP § 706.07(a) are met. As noted in the 
preceding paragraphs, such conditions are clearly not met. Accordingly, it is respectfully submitted 
that the finality indicated in the current Office Action is premature, and as such, withdrawal of this 
indicated finality is respectfully requested. 

III. Claim Rejections - 35 U.S.C. $ 102 

Claims 12, 13 and 18 are rejected under 35 U.S.C. 102(e) as being anticipated by Lu et al. 
US Patent No. 7,281,036 (hereafter Lu). 

With this paper, Claims 12 and 13 have been amended to further clarify the difference, and 
thus patentability, between the previously applied prior art and inventions respectively claimed 
therein. Specifically, the operations of the network device have clarified with respect to the receipt 
of a broadcast frame. This clarification further substantiates the nature of the broadcast frame from 
the management node as being that of a "force request". Support for this amendment can be found 
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throughout the application, as originally filed, and particularly in paragraph [0016] of the 
specification. 

Claim 12, as amended, is reproduced for convenience as follows: 
12. A system comprising: 

a network element including a direct internet protocol module, the network element 
changing its current protocol address to an IP address specified in a broadcast frame, wherein the 
change is made after receiving the broadcast frame; and 

a management node residing at a same physical subnet as the network element, the 
management node comprising computer executable instructions that when executed perform actions 
including: 

forcing the network element to have an unused IP address within an access range of 
the management node by: 

(i) identifying the unused IP address within the access range of the management 
node; and 

(ii) broadcasting the broadcast frame from the management node as a force 
request including the unused IP address to the direct internet protocol module without 
reconfiguring the management node, wherein the broadcast frame from the management 
node to the direct internet protocol module is constructed to change the IP address of the 
network element from its current protocol address to the unused IP address. 

After carefully and thoroughly reviewing the most recent Office Action, it is respectfully 
submitted that the prior art applied therein neither anticipates nor renders obvious the limitations 
reproduced above, including when such limitations are collectively considered as a whole. 

On the whole, it is respectfully submitted that this prior art fails to at least anticipate or 
render obvious the limitations of Claim 12 that pertain to a 'force request" that is sent from a 
management node to a network device. As is further explained herein, the details, features, and 
implementation of this 'force request" is not taught or suggested by the prior art of record, 
including as it is further claimed in at least Claim 12. 
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In response to the discussion of the applied references herein, if any of the current rejections 
are maintained in response to this application, it is respectfully requested that such rejections be 
explained with respect to at least the limitations related to a "force request". In regards to future 
Office Actions, assistance is also requested with regards to better clarifying the manner in which the 
references are being interpreted and applied. The citation of references by column or page, absent 
lines or event element numbers (see lines 1-8 of page 3 of the current Office Action, for example), 
does not clearly explain the pertinence of such references, including as is practicable, as is further 
discussed in 37 CFR 1.104(c)(2). 

With regards to the first reference applied under 35 U.S.C. § 102(e), Lu discloses a network 
device that determines a network address for itself, and then assumes this address for itself (col. 7, 
lines 26-32 of Lu). To reiterate, in these steps (i) and (ii) of Lu, the appliance (110) initiates, 
organizes, and controls the determination of its own network address. When an external device, a 
central appliance server (150) is formally addressed by the appliance (110), it is at the request and 
access of the appliance (110), not that of the central server (col. 7, lines 35-44 of Lu). Lu also 
discloses a situation where, during attempts to locate an unused network address, the appliance 
(110) performs a corrective action for an address that is tested but already assigned (col. 16, lines 
27-38). However, this routine involves restoring a previously assigned address, ip_Y, to its 
assigned device, which involves neither an unused address, nor an address that is received and can 
be assumed by the appliance (110) of Lu (col. 16, lines 27-30). 

In contrast, Claim 12, as reproduced above, comprises two devices - a "management node" 
and a "network element", wherein the former device forces the latter to have a specific IP address by 
sending an "unused IP address" to the latter, wherein the "network element" changes its IP address 
from a "its current protocol address " to the "unused IP address " from the management node "after 
receiving the broadcast frame". As noted above, the same device in Lu, appliance (110), sends a 
message with a candidate unused IP address (col. 15, lines 61-63) and assumes the unused IP 
address after a variety of checks on the potentially unused address (col. 24, lines 58-60). Such an 
arrangement does not teach or suggest a system comprising a network element and a management 
node as claimed, much less "a management node" that performs actions including "broadcasting 
the broadcast frame from the management node as a force request including the unused IP address 
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to the direct internet protocol module" as is further claimed in Claim 12. In such an arrangement, 
the appliance (1 10) of Lu does not teach or suggest the claimed "network element" so far as it first 
pretends to have the candidate unused IP address (col. 15, lines 61-63), the use of which by the 
appliance (110) is thus not "after receiving the broadcast frame" as claimed in Claim 12. The 
appliance (1 10) of Lu does not teach or suggest the "management node", as claimed in Claim 12, so 
far as it pretends to have a plurality of difference IP addresses, and this does not operate "without 
reconfiguring the management node" . The polling of such candidate unused IP addresses also does 
not teach or suggest the claimed "management node" so far as the IMCP and ARP requests in Lu 
(col. 15, lines 61-63; col. 16, lines 13-25) wait for ARP requests or ARP replies (col. 16, lines 4-9 
and 15-21), which indicates that these requests from the appliance (110) are not "constructed to 
change the IP address of the network element from its current protocol address to the unused IP 
address" as further claimed in Claim 12. The teachings of Lu regarding the IP conflict (col. 16, 
lines 27 - col. 17, line 5) involve an IP address "has already been assigned to another machine", 
which is not equivalent to or suggestive of the "identifying the unused IP address" as further 
claimed in at least Claim 12. Finally, the permanent IP address received by the appliance (110) is 
received in a frame sent to the appliance (1 10) by the central management server after the appliance 
(110) has contacted the server (150), and thus not at the forcing or request of the server (150)(col. 
25, lines 25-37), which fails to teach or suggest the forcing and sending of this permanent address 
"from the management node as a force request" as is further claimed in at least Claim 12. Forcing 
a change in address, as claimed, is simply not equivalent in scope to self-assuming or requesting the 
receipt of an address as is performed in Lu, at least so far as the element that receives a forcing 
broadcast frame does not have control or initiation of such a resulting change. The permanent IP 
address from the server (150) is also in the subnet of the appliance (110) and not the server 
(150)(Figure 1 of Lu and col. 25, lines 57-62), which fails to teach or suggest "unused IP address 
within the access range of the management node" as further claimed in at least Claim 12. 
Accordingly, it is respectfully submitted that Lu does not teach or suggest all limitations of Claim 
12, including when such limitations are collectively considered as a whole. As such withdrawal of 
the previous rejection of this claim under 35 U.S.C. § 102(e) is respectfully requested. 
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With regards to the two "Notes" provided in the most recent Office Action, it is respectfully 
submitted that the amendment to Claim 12 clarifies that the features following the "wherein" terms 
in the claims are required to be part of the claimed "system", thus obviating the discussion of MPEP 
2111 with regards to these features. It is also respectfully submitted that the limitations of at least 
Claims 12-18 set forth the claimed invention in a manner that, even when given its broadest 
reasonable interpretation in light of the specification, it is not anticipated nor rendered obvious by 
the prior art of record - including Lu. As such, it is respectfully submitted that the two issues noted 
in these "Notes" have been herein addressed and obviated. 

For Claim 13, as is similarly set forth for Claim 12, the teachings of Lu involve a plurality 
of different frames before a permanent IP address is sent (col. 7, lines 26-40 of Lu), which fails to at 
least suggest "and wherein broadcasting the broadcast frame permits connection between the 
management node and the network device using TCP/IP after the exchange of only three Ethernet 
frames" as is further claimed in at least Claim 13. Accordingly withdrawal of the previous rejection 
under 35 U.S.C. § 102(e) is also respectfully requested. 

So far as Claim 18 depends on Claim 12, it is respectfully submitted that the remarks 
presented herein regarding Lu and Claim 12 also apply to the limitations of Claim 18. Accordingly, 
for at least the same reasons, withdrawal of this rejection under 35 U.S.C. § 102(e) is respectfully 
requested. 

Claims 12, 13 and 18 are rejected under 35 U.S.C. 102(e) as being anticipated by Sawyer et 
al. US Patent No. 6,466,986 (hereafter Sawyer). 

Similar to Lu, it is respectfully submitted that Sawyer fails to anticipate or render obvious at 
least the limitations of Claim 12 that pertain to a 'force request" that is sent from a management 
node to a network device. 

Sawyer discloses a system for associating a MAC address of a client device with the IP 
address of a client device (col. 1, lines 38-52). Regarding IP addresses, the system of Sawyer is 
based on the DHCP protocol (col. 2, lines 5-7). As noted in previous responses with regards to the 
teachings of Gai-Cisco, such a protocol comprises a user device (120) initiating the process of 
obtaining an IP address from a DHCP server (140) (col. 2, lines 34-37; col. 3, lines 28-30). After 
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this initiation by the user device (120), the server responds with an offered IP address (col. 4, lines 
23-24), upon which the client device responds with a request for the offered address (col. 4, lines 
38-40), and which is then responded to by the server (140) with an acknowledgement that is sent to 
the client (120) (col. 4, lines 56-60). The teachings of Sawyer, with regard to this protocol, pertain 
to tracking the parity between a MAC address of a device and the IP address that is assigned to such 
as device to ensure secure routing of future messages between the user device (120) and the internet 
(via a router 150) by checking and enforcing the tracked parity (col. 5, lines 25-59 of Sawyer). 

As stated before with respect to Gai-Cisco, at least the "force request" aspect of the 
invention claimed in Claim 12 is not taught or suggested by the DHCP protocol. For Sawyer, the 
user device (120) that initiates (col. 3, lines 28-30) and requests an IP address (col. 4, lines 38-40) is 
the same device that selects and uses a particular address (col. 4, lines 45-51; col. 5, lines 35-59). 
Such an arrangement does not teach or suggest a system comprising a network element and a 
management node as claimed, much less a management node" that performs actions including 
"broadcasting the broadcast frame from the management node as a force request" as is further 
claimed in Claim 12. The difference between "forcing" and "force", as claimed in at least Claim 
12, is clearly demonstrated by the "provisional" marking of the IP address table at the server (140) 
(col. 4, lines 20-22 in Sawyer), as well as the fact that the user device (120) - not a server - selects a 
DHCP server and the address offered by the DHCP server (col. 4, lines 45-5 1). The DHCP server 
(140) of Sawyer does not teach or suggest the claimed "management node" so far as the selection of 
the server (140), and corresponding address, is done by the user device (120) in Sawyer (col. 5, lines 
45-5 1) and thus these offers from the server (140) are not "constructed to change the IP address of 
the network element from its current protocol address to the unused IP address " as further claimed 
in Claim 12. The wait for the response at the server (120) for the request (REQUEST) from the user 
device, upon which the table at the server (140) is then changed (col. 4, lines 54-56 of Sawyer), 
does not teach or suggest "wherein the broadcast frame from the management node to the direct 
internet protocol module is constructed to change the IP address of the network element from its 
current protocol address to the unused IP address " as further claimed in Claim 12. In fact, it is 
respectfully submitted that, prior to the DHCP-based interaction between the user device (120) and 
the server (140), the user device (120) does not have an IP address to access the internet backbone 



{S:\08204\0203163-us0\80170103.DOC 



16 



Application No. 09/826,266 DocketNo.: 08204/0203163-US0/10.176 

Amendment dated April 21, 2008 

After Final Office Action of February 21, 2008 

(155) in Sawyer (col. 2, lines 34-35), which does not teach or suggest "the network element 
changing its current protocol address to an IP address specified in a broadcast frame ". 
Accordingly, for at least these reasons, it is respectfully submitted that Sawyer does not teach or 
suggest all limitations of Claim 12, including when such limitations are collectively considered as a 
whole. As such withdrawal of the previous rejection of this claim under 35 U.S.C. § 102(e) is 
respectfully requested. 

Similarly, for Claim 13, the teachings of Sawyer involve at least four (discover, offer, 
request, acknowledgement) different frames before an IP address is established for use by the user 
device (120) (col. 4, lines 18-24 and 54-60 of Sawyer), which fails to at least suggest "and wherein 
broadcasting the broadcast frame permits connection between the management node and the 
network device using TCP/IP after the exchange of only three Ethernet frames'" as is further claimed 
in at least Claim 13. Accordingly withdrawal of the previous rejection under 35 U.S.C. § 102(e) is 
also respectfully requested. 

So far as Claim 18 depends on Claim 12, it is respectfully submitted that the remarks 
presented herein regarding Sawyer and Claim 12 also apply to the limitations of Claim 18. 
Accordingly, for at least the same reasons, withdrawal of this rejection under 35 U.S.C. § 102(e) is 
respectfully requested. 

Claims 12, 13 and 18 are rejected under 35 U.S.C. 102(e) as being anticipated by Pham et 
al. US Patent No. 6,629,145 (hereafter Pham). 

Similar to Lu, it is respectfully submitted that Pham fails to anticipate or render obvious at 
least the limitations of Claim 12 that pertain to a "force request" that is sent from a management 
node to a network device. 

Pham discloses a system that enables a server device to configure itself with an initial set of 
network values, and then interact with a second system to determine a second set of network values 
(abstract, col. 3, lines 1-6). The first phase comprises the assumption of a default IP address by the 
server device (12)(col. 6, lines 62-66). This phase also involves IP address conflict resolution, 
which the server (12) performs for itself, and which concludes in the selection of an unused address 
by the server (12) as a second IP address, an alias IP address (col. 8, lines 46-52 and col. 9, lines 19- 
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23 of Pham). The second phase of configuration comprises the server device setting its own IP 
address for a given network (col. 13, lines 24-27) and then offers this IP address to a configuration 
control client (22,100) as a selectable option (col. 13, lines 27-31). 

In contrast with the claimed invention of at least Claim 12, these teachings of Pham reflect 
the similar deficiencies of Lu with regards to the "force request" as claimed. In both phases of 
operation of the system of Pham, the same system (12) that determines an IP address is the system 
(12) that assumes the IP address (col. 6, lines 62-67 and col. 13, lines 24-27 of Pham), which fails to 
teach or suggest "a management node" that performs actions including "broadcasting the broadcast 
frame from the management node as a force request including the unused IP address to the direct 
internet protocol module" as is further claimed in Claim 12. In such an arrangement, the server 
device (12), which also runs the configure management application (56) of Pham, does not teach or 
suggest the claimed "network element" so far as it sets its own address before providing the address 
to a control application (100) on a separate device (22) (col. 13, lines 26-27), which is not "after 
receiving the broadcast frame" as claimed in Claim 12. The server (12) of Lu does not teach or 
suggest the "management node", as claimed in Claim 12 so far as it accepts two different sets of 
initial and secondary sets of network values (Abstract of Pham), which does not comprise operating 
"without reconfiguring the management node". The polling of unused IP addresses by the server 
(12), rather then the control system (22), fails to teach or suggest the same device performing 
actions of both "forcing the network element to have an unused IP address" and "identifying the 
unused IP address within the access range of the management node " as is further claimed for the 
"management node", not the network element of Claim 12. The assumption and use of a previously 
configured value by the server (12)(col. 6, lines 63-67 of Pham) also fails to teach or suggest 
"identifying the unused IP address within the access range of the management node " for the server 
(12) itself, much less as is further claimed for the "management node" of Claim 12. The response 
from the second device (22), which runs a configuration control client, comprises acknowledging 
the settings determined by the server (12) for itself, which fails to teach or suggest the forcing and 
sending of this configuration involving an address "from the management node as a force request" 
as is further claimed in at least Claim 12. To reiterate, forcing a change in address, as claimed, is 
simply not equivalent in scope to self-assuming and then obtaining approval or an indication of 
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conflict, as is performed in Lu, at least so far as the device that receives the forcing broadcast frame 
does not have overall control or initiation of such a resulting change. In fact, Pham particular notes 
that the server (12) forces a configuration control client (100 in 22) to accept an address setting that 
it has determined for itself (col. 13, lines 24-27 and 53-58), which clearly differs from the 
management node "forcing the network element to have an unused IP address" as is further claimed 
in Claim 12. Accordingly, it is respectfully submitted that Lu does not teach or suggest all 
limitations of Claim 12, including when such limitations are collectively considered as a whole. As 
such withdrawal of the previous rejection of this claim under 35 U.S.C. § 102(e) is respectfully 
requested. 

For Claim 13, the teachings of Pham involve a plurality of messages sent and received 
before an IP address is established for between the server (12) and the control device (22) (col. 7, 
lines 45-48, and col. 10, lines 14-17, and col. 12, lines 21-25, and col. 13, lines 29-31of Pham) 
which fails to at least suggest "and wherein broadcasting the broadcast frame permits connection 
between the management node and the network device using TCP/IP after the exchange of only 
three Ethernet frames" as is further claimed in at least Claim 13. Accordingly withdrawal of the 
previous rejection under 35 U.S.C. § 102(e) is also respectfully requested. 

So far as Claim 18 depends on Claim 12, it is respectfully submitted that the remarks 
presented herein regarding Pham and Claim 12 also apply to the limitations of Claim 18. 
Accordingly, for at least the same reasons, withdrawal of this rejection under 35 U.S.C. § 102(e) is 
respectfully requested. 

Claims 12, 13 and 18 are rejected under 35 U.S.C. 102(e) as being anticipated by Short et 
al. US Patent Publication No. 2005/0188092 (hereafter Short). 

Similar to Lu, Sawyer, and Pham, it is respectfully submitted that Short fails to anticipate or 
render obvious at least the limitations of Claim 12 that pertain to a "force request" that is sent from 
a management node to a network device. 

Short discloses an intermediate device (router 10) that is able to variably connect a host 
device (12) with a network (14)(para. [0044-0046]). The router (10) connects, in separate manners, 
with both the host device (12) and the network (14), and enables the relative communication 
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therebetween by translating packets between the two components (para. 0104, 0109, 0119). The 
router (10) then transparently represents the (12) to the network (14) and vice versa (para. 0057). 

While the interpretation of reference of Short is unclear from the Office Action, since entire 
pages (4,7 in Short) are cited in the Office Action, it is yet respectfully submitted that no 
combination of the three main components discussed in Short (10,12,14), teach or suggest the 
limitations of Claim 12, including those particularly related to the "force request" as claimed. For 
example, the host device (12) utilizes a permanent internet address (para. 0048), which fails to teach 
or suggest "the network element changing its current protocol address to an IP address specified in 
a broadcast frame ", much less "forcing the network element to have an unused IP address within 
an access range of the management node ". To establish connection between the router (10) and the 
network (14) or router (26), the router (10) of Short implements the DHCP protocol (para. 0121), 
elects its own IP address (para. 0125-0126), or manually receives the configuration information 
(para. 0128 of Short). The use of the DHCP protocol, as well as self-configuration by the same 
device that ultimately employs a determined IP address, are discussed above, in detail, with regards 
to the teachings of Lu, Sawyer, and Pham. It is respectfully submitted that the teaching of Short do 
not teach or suggest the limitations of Claim 12 for at least similar reasons, particularly including 
that in such an arrangement, the router (10) of Short does not change "its current protocol address 
to an IP address specified in a broadcast frame, wherein the change is made after receiving the 
broadcast frame ", nor is the router equivalent to or suggestive of a "management node " capable of 
"forcing the network element to have an unused IP address within an access range of the 
management node " and "broadcasting the broadcast frame from the management node as a force 
request including the unused IP address to the direct internet protocol module without 
reconfiguring the management node, wherein the broadcast frame from the management node to the 
direct internet protocol module is constructed to change the IP address of the network element from 
its current protocol address to the unused IP address " as is further claimed in Claim 12. Manual 
entry of configuration information (para. 0128 of Short), clearly does not cure this deficiency. 
Accordingly, withdrawal of the rejections of amended Claim 12, as well as those of Claims 13 and 
18, is respectfully requested, at least in light of the reasoning further discussed above with regards 
to the references of Lu, Sawyer, and Pham. Again, it is respectfully submitted that the limitations of 
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these claims are neither anticipated, nor rendered obvious by the reference of Short, including when 
the effect of these limitations is considered as a whole. 

IV. Claim Rejections - 35 U.S.C. $ 103 

Claims 12, 13 and 18 are rejected under 35 U.S.C. 103(a) as being unpatentable over Gai et 
al, US Patent No. 6,697,360, Cisco (hereafter Gai-Cisco) in view of Oran et al, US Patent No. 
6,240,084, Cisco (hereafter Oran-Cisco). 

As noted above, and similar to Sawyer, it is respectfully submitted that Gai-Cisco, even in 
combination with Oran-Cisco fails to anticipate or render obvious at least the limitations of Claim 
12 that pertain to a "force request" that is sent from a management node to a network device. 

As was stated previously, the teachings of Gai-Cisco specifically center on the ability of an 
intermediate device, as an extension of the DHCP protocol, to request and receive IP addresses for 
itself (col. 5, lines 34-40 of Gai-Cisco). Alternately stated, the intermediate device, the device to 
which an IP address is given, is the same device that first requests the IP address. For example, the 
DHCPDISCOVER message from an intermediate device of a switch 214, is set to "request", as part 
of the initial step of acquiring a stable IP address (col. 8, lines 18-34). The response to this initial 
DHCPDISCOVER message from a server, such a 220 or 222, is not indicated as a request, but 
rather a "reply" as part of a DHCPOFFER message (col. 9, lines 21-23 and 28-36). The switch 214 
then proceeds to select at least one of the received IP addresses that it initially requested (col. 10, 
lines 19-22). This pattern of a switch request, followed by a server reply, is repeated throughout the 
communication arrangement of Gai-Cisco (see, for example, switch requests in col. 11, lines 26-30 
and col. 13, lines 16-33). 

However, an "offer" or something "proffered" is not the same as a request, nor is it a 
representation of force. Such a difference is even recognized in the language of Gai-Cisco cited 
above. In fact, the messaging noted in Gai-Cisco to be initiated from a server, such as 220, does not 
contain an unused IP address, but rather, is simply a ROUTER RECONFIG message. This 
message, even in such circumstances, still results in the switch - not the server - initiating and 
requesting configuration of a new connection (col. 16, lines 34-42). Again, the end user of the IP 
address, the switch, is the source of these requests in Gai-Cisco, not the server. 
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In contrast, the claimed invention, as represented in amended Claim 12, clearly recites that 
the unused IP address is issued as part of a force request from a management node, at least by way 
of the limitation "broadcasting the broadcast frame from the management node as a force request 
including the unused IP address". The nature of the unused IP address, received and used by a 
second device (i.e., the "network element"), is further represented in the claim at least by the 
limitations "from the management node" and "the network element changing its current protocol 
address to an IP address specified in a broadcast frame". As further detailed above, this 
relationship is different than that expressed in the DHCP-based relationship of the server and switch 
in Gai-Cisco, noting that the "server" of Gai-Cisco appears to have been equated in the most recent 
Office Action to the claimed "management node", while the "switch" appears to have been equated 
to the claimed "network element". Further, the ROUTER RECONFIG is addressed to the interface 
being affected (col. 16, lines 37-42 of Gai-Cisco), but does not include a new IP address, which fails 
to teach or suggest "broadcasting a broadcast frame from the management node as a force request 
including the unused IP address" . The addition and use of a second IP address to the server (col. 
16, lines 54-57 in Gai-Cisco) fails to teach or suggest "the network element changing its current 
protocol address to an IP address specified in a broadcast frame ". The fact that this second IP 
address is added after a message from the switch to the server (col. 16, lines 47-49 in Gai-Cisco) 
also fails to teach or suggest "the broadcast frame from the management node to the direct internet 
protocol module is constructed to change the IP address of the network element from its current 
protocol address to the unused IP address" as is further claimed in Claim 12. It is respectfully 
submitted that such differences underscore at least one distinction, and thus grounds for 
patentability, between the applied "server" and "switch" of Gai-Cisco and the "management node" 
and the "network element" as further claimed in at least Claim 12. 

It is respectfully submitted that Oran-Cisco does not cure the above noted deficiency in the 
teachings of Gai-Cisco. Oran-Cisco discloses a PC based server platform that includes a bus that 
connects router cards (14) to telephony endpoint cards (16) (col. 2, lines 52-64). An IP-based wide 
area network is mentioned in the teachings, but not in terms of the transfer of an unused IP address, 
including such as represented in the amended limitation of Claim 12 discussed above (see col. 2, 
lines 59-64 of Oran-Cisco). In fact, a second network device, aside from the server of Figure 2, is 
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not even shown in the Figures of Oran-Cisco, much less discussed in the detailed description in a 
manner that would teach or suggest the above noted limitation of amended Claim 12. For at least 
this reason, it is respectfully submitted that Oran-Cisco, alone or even in further combination with 
Gai-Cisco, does not teach or suggest this limitation. 

For at least the reasons presented herein, it is respectfully submitted that, as amended, Claim 
12, as a whole, is not taught or suggested by the combined teachings of Gai-Cisco in view of Oran- 
Cisco. Accordingly, withdrawal of the rejection of this claim under 35 U.S.C. §103(a) is 
respectfully requested. 

Similarly, for Claim 13, the teachings of Gai-Cisco involve at least four (discover, offer, 
request, acknowledgement) different frames before an IP address is established for use by the switch 
(Figure 3 of Sawyer) or even more frames if a change is made between subnets (Figure 5 of Gai- 
Cisco), which fails to at least suggest "and wherein broadcasting the broadcast frame permits 
connection between the management node and the network device using TCP/IP after the exchange 
of only three Ethernet frames" as is further claimed in at least Claim 13. Accordingly withdrawal of 
the previous rejection under 35 U.S.C. § 103(a) is also respectfully requested. 

So far as Claim 18 depends from Claim 12, it is respectfully submitted that these claims 
incorporate the above noted limitation of Claim 12, and are not taught or suggested by the 
combination of Gai-Cisco and Oran-Cisco for at least the same reasons presented herein. 
Accordingly, withdrawal of this rejection under 35 U.S.C. § 103(a) is also respectfully requested. 

Claims 14 and 17 are rejected under 35 U.S.C. 103(a) as being unpatentable over Lu in 
view of Ullmann et al, IBM, US Patent Publication No. 2002/0172222 (hereafter Ullmann-IBM). 
Claims 14 and 17 are rejected under 35 U.S.C. 103(a) as being unpatentable over Gai-Cisco and 
Oran-Cisco in view of Ullmann et al, IBM, US Patent Publication No. 2002/0172222 (hereafter 
Ullmann-IBM). Claims 14 and 17 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Sawyer in view of Ullmann et al, IBM, US Patent Publication 2002/0172222 (hereafter Ullmann- 
IBM). Claims 14 and 17 are rejected under 35 U.S.C. 103(a) as being unpatentable over Pham in 
view of Ullmann et al, IBM, US Patent Publication 2002/0172222 (hereafter Ullmann-IBM). 
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Claims 14 and 17 are rejected under 35 U.S.C. 103(a) as being unpatentable over Short in view of 
Ullmann et al, IBM, US Patent Publication 2002/0172222 (hereafter Ullmann-IBM). 

However, so far as Claims 14 and 17 depend from Claim 12, it is respectfully submitted that 
these claims incorporate the above noted limitation of Claim 12, and are not taught or suggested by 
Lu, Short, Sawyer, Pham or the combination of Gai-Cisco and Oran-Cisco for at least the same 
reasons. It is respectfully submitted that the IP-related teachings of the network of Ullmann-IBM, 
mentioned for example in paragraphs [0064] and [0093], do not cure the above noted deficiencies. 
Accordingly, withdrawal of these rejections under 35 U.S.C. § 103(a) is also respectfully requested. 

Claims 15 and 16 are rejected under 35 U.S.C. 103(a) as being unpatentable over Lu in 
view of Fuoco et al, US Patent No. 6,594,713, Texas Instruments (hereafter Fuoco-Texas). Claims 
15 and 16 are also rejected under 35 U.S.C. 103(a) as being unpatentable over Gai-Cisco and Oran- 
Cisco in view of Fuoco et al, US Patent No. 6,594,713, Texas Instruments (hereafter Fuoco-Texas). 
Claims 15 and 16 are rejected under 35 U.S.C. 103(a) as being unpatentable over Sawyer in view 
of Fuoco et al, US Patent No. 6,594,713, Texas Instruments (hereafter Fuoco-Texas). Claims 15 
and 16 are rejected under 35 U.S.C. 103(a) as being unpatentable over Pham in view of Fuoco et 
al, US Patent No. 6,594,713, Texas Instruments (hereafter Fuoco-Texas). Claims 15 and 16 are 
rejected under 35 U.S.C. 103(a) as being unpatentable over Short in view of Fuoco et al, US Patent 
No. 6,594,713, Texas Instruments (hereafter Fuoco-Texas). 

However, so far as Claims 15 and 16 depend directly or indirectly from Claim 12, it is 
respectfully submitted that these claims incorporate the above noted limitation of Claim 12, and are 
not taught or suggested by Lu, Pham, Sawyer, Short, or the combination of Gai-Cisco and Oran- 
Cisco for at least the same reasons. It is respectfully submitted that the external port interface related 
teachings of Fuoco-Texas, mentioned for example in col. 8, lines 33-39 do not cure the deficiencies 
of the Lu, Pham, Sawyer, Short, or the combination of Gai-Cisco and Oran-Cisco as is further 
presented herein. Accordingly, withdrawal of these rejections under 35 U.S.C. § 103(a) is also 
respectfully requested. 

With particular regard to Claim 16, it is also respectfully submitted that the notions of 
"disabled" and "time after power up", as further claimed in Claim 16, are not taught or suggested by 
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Fuoco-Texas. The Office Action, in section 13 on page 6, section 22 on page 10, section 22 on page 
10, section 22 on page 10, and section 22 on page 10, indicates that Gai-Cisco and Oran-Cisco do 
not teach such limitations. These references to Gai-Cisco and Oran-Cisco in sections of the Office 
Action that do not involve these references, such as those that apply to Sawyer, Short, Pham, and 
Lu, are interpreted herein to be a typographical error, and also intend to indicate that these four 
references do not teach or suggest the limitations of Claims 15 and 16 either. 

However, "forced", as suggested by Gai-Cisco in column 15, line 55, and "disabled" as 
claimed in Claim 16, are clearly different concepts, at least so far as they initiate from and pertain to 
different ends of a communication system. Fuoco-Texas, however, in the cited figures of 1, 3, and 
10, and the passage cited of Figure 8 does not mention these concepts of Claim 16 either. Clearly, a 
conclusion of obviousness cannot be reached in view of such silence , including that of the cited 
portions of Fuoco-Texas. Withdrawal of the previous rejections based on Fuoco and Claim 16 is 
thus respectfully requested. 

In fact, it is respectfully submitted that amending such a feature as claimed in Claim 16 to 
the teachings of Gai-Cisco would render the system of Gai-Cisco inoperable for its intended 
purpose. Namely, the ability to automatically modify subnets would be expressly inhibited by such 
an added feature, since the ability to reconfigure would be disabled after the claimed 
"predetermined amount of time after power up" of Claim 16 (see col. 16, lines 28-42 of Gai-Cisco). 
Again, the concept of '"predetermined time after power up", as further claimed in Claim 16, is not 
mentioned, much less suggested by the cited teachings of Gai-Cisco, Oran-Cisco, and Fuoco-Texas. 
It is respectfully submitted that this same inconsistency exists in a similar form between Fuoco- 
Texas and the other newly-cited references of Lu, Sawyer, Pham, and particularly Short. 

On these additional grounds of failure to at least suggest the limitations of Claim 16, as well 
as the incompatibility of any such combination, it is respectfully requested that the rejections of 
Claim 16 be withdrawn as well. 
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CONCLUSION 

In view of the above amendment, applicant's representative believes the pending 
application is in condition for allowance. 

Dated: April 21, 2008 Respectfully submitted, 

By_/John W. Branch/ 

John W. Branch 

Registration No.: 41,633 
DARBY & DARBY P.C. 
P.O. BOX 770 
Church Street Station 
New York, NY 10008-0770 
(206) 262-8906 
(212) 527-7701 (Fax) 
Attorneys/ Agents For Applicant 
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